In message 
<1fee3f8f5ccde64c9a8e8f4ad27c19ee0820c...@nkgeml512-mbs.china.huawei.com>
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.
> 
> Any comments and suggestions are welcome.
> 
> Best regards,
> Xiaohu


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
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to