Subject: [OSPF] 转发: New Version Notification for draft-xu-mpls-el-capability-signaling-igp-00.txt

From: Xuxiaohu <[email-masked]>
Date: Tue, 10 Sep 2013 00:59:05 +0000

> -----邮件原件-----
> 发件人: Xuxiaohu
> 发送时间: 2013年9月10日 8:56
> 收件人: [email-masked]; [email-masked] list; [email-masked]'
> 主题: fwd: New Version Notification for
> draft-xu-mpls-el-capability-signaling-igp-00.txt
> 
> Hi all,
> 
> The following draft defines a mechanism to signal the Entropy Label Capability
> (ELC) using ISIS and OSPF, which is applicable in the case where the label
> advertisement is also
> done via that IGP.
> 
> Any comments and suggestions are welcome.
> 
> Best regards,
> Xiaohu
> 
> > -----邮件原件-----
> > 发件人: [email-masked] [mailto:[email-masked]]
> > 发送时间: 2013年9月6日 8:59
> > 收件人: Clarence Filsfils; Sriganesh Kini; Xuxiaohu; Siva Sivabalan; Xuxiaohu
> > 主题: New Version Notification for
> > draft-xu-mpls-el-capability-signaling-igp-00.txt
> >
> >
> > A new version of I-D, draft-xu-mpls-el-capability-signaling-igp-00.txt
> > has been successfully submitted by Xiaohu Xu and posted to the
> > IETF repository.
> >
> > Filename:	 draft-xu-mpls-el-capability-signaling-igp
> > Revision:	 00
> > Title:		 Signaling Entropy Label Capability Using Interior Gateway
> Protocols
> > Creation date:	 2013-09-06
> > Group:		 Individual Submission
> > Number of pages: 5
> > URL:
> >
> http://www.ietf.org/internet-drafts/draft-xu-mpls-el-capability-signaling-igp-00.t
> > xt
> > Status:
> > http://datatracker.ietf.org/doc/draft-xu-mpls-el-capability-signaling-igp
> > Htmlized:
> > http://tools.ietf.org/html/draft-xu-mpls-el-capability-signaling-igp-00
> >
> >
> > Abstract:
> >    Multi Protocol Label Switching (MPLS) has defined a mechanism to load
> >    balance traffic flows using Entropy Labels (EL).  An LSR inserts the
> >    EL Indicator and the EL label only if the LSR that pops them has the
> >    capability of processing them.  This draft defines a mechanism to
> >    signal that capability using link state Interior Gateway Protocols
> >    (IGP).  This mechanism is useful when the label advertisement is also
> >    done via that IGP.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Sep 2013 11:02:11 -0400

In message <[email-masked]>
Xuxiaohu writes:

> Hi all,
> 
> The following draft defines a mechanism to signal the Entropy Label
> Capability (ELC) using ISIS and OSPF, which is applicable in the
> case where the label advertisement is also done via that IGP.
> 

Xiaohu,

This is a short document and it uses the OSPF Router Information (RI)
Opaque LSA defined in [RFC4970] and IS-IS Router CAPABILITY TLV
defined in [RFC4971].

That won't work if some of the interfaces are ELC and others are not.
This would be a common case in transition or after transition if a
spare card was not ELC but otherwise useable and was needed after a
card failure.

ELC must be on a per interface basis.

While you are at it, please also consider including the following

  0) whether the interface can terminate an LSP with ELI and EL (aka
     ELC, what you planned to cover),

  1) whether the interface can find an ELI and EL in the label stack
     and make use of it,

  2) at what maximum depth can the entropy occur (maybe 0 for more
     than 255 or more than 65535 which would be absurd),

  3) whether the search for entropy is terminated when the EL is
     encountered (RFC6790 says "SHOULD" and some people including me
     think that should have been a "MUST"),

  4) whether reserved labels are ignored (may matter for GAL,
     therefore MPLS-TP protected by EL),

  5) whether reserved extended labels are ignored,

  6) whether the interface will look below the stack for entropy (ie:
     looks for 4 or 6 in first payload nibble and needs PWE CW if
     payload is not IP).

Note that for MPLS-TP to be carried protected by ELI and EL, #1 plus
either #3 or #4 (or both) must be true.  Also note that #4 and #5 can
be true even if #0 and #1 are not true and #4 would be sufficient for
MPLS-TP with no labels under the stack.

These would be better in a bit map in one TLV rather than one TLV each
(though #2 needs an integer).

Curtis