Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

["Acee Lindem (acee)" <[e-mail]>]

Hi Peter, 
Thanks - hopefully this will more than satisfy Ben's discuss.
Acee

On 5/26/20, 10:25 AM, "Peter Psenak" <[e-mail]> wrote:

    Hi Acee,

    updated the text based on your comments.

    thanks,
    Peter


    On 26/05/2020 16:07, Acee Lindem (acee) wrote:
    > Hi Peter,
    > 
    > This is in response to the previous Email on your suggested text.
    > 
    > On 5/26/20, 4:26 AM, "Peter Psenak" <[e-mail]> wrote:
    > 
    >      Hi Alvaro,
    > 
    >      please see inline (##PP)
    > 
    >      On 22/05/2020 16:59, Alvaro Retana wrote:
    >      > On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote:
    >      >
    >      >
    >      > Peter:
    >      >
    >      > Hi!
    >      >
    >      >
    >      >> With respect to Alvaro's clarification, your answer for (1) makes sense;
    >      >> thanks! I think Alvaro has offered to help work out what (if any)
    >      >> additional text we might want to be sure that the answer to (2) is clear in
    >      >> the document.
    >      >
    >      > I think that #1 is where some clarification could be useful. :-)
    >      >
    >      >
    >      > I'm including both ISIS and OSPF suggestions below to consolidate the
    >      > discussion.
    >      >
    >      >
    >      > ...
    >      >>> My interpretation of Ben's question is two-fold:
    >      >>>
    >      >>> (1) Would ISIS routers normally propagate the information to a
    >      >>> different level? The ELC is a new prefix attribute flag -- are prefix
    >      >>> attributes always propagated (unchanged) to other levels? If so, then
    >      >>> the requirement (MUST) is not needed. My reading of rfc7794 is that
    >      >>> the propagation is optional...
    >      >>
    >      >> depends on the attribute or a bit. Some are propagated some are not.
    >      >> That's why we are saying this one MUST be preserved.
    >      >
    >      > Right.
    >      >
    >      > For ISIS I think the current text is in line with the specification of
    >      > the other bits in rfc7794.  No changes are needed.
    >      >
    >      > If anything, you may want to change the order of this sentence to
    >      > address Ben's comment:
    >      >
    >      > OLD>
    >      >     When a router propagates a prefix between ISIS levels ([RFC5302], it
    >      >     MUST preserve the ELC signaling for this prefix.
    >      >
    >      > NEW>
    >      >     The ELC signaling MUST be preserved when a router propagates a prefix
    >      >     between ISIS levels ([RFC5302]).
    >      >
    >      > [Similar for OSPF.]
    > 
    >      ##PP
    >      done.
    > 
    > 
    >      >
    >      >
    >      >
    >      > I think that for OSPF it is not that simple...
    >      >
    >      > For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix
    >      > Opaque LSA depends on the scope of the advertised prefixes", which I
    >      > assume means that for intra-area prefixes the scope will be
    >      > area-local...so the ABR wouldn't simply propagate it; it would have to
    >      > originate a new LSA.
    > 
    >      ##PP
    >      correct. It is always a new LSA that ABR needs to generate. Here it's
    >      actually two LSAs.
    > 
    >      >
    >      > Suggestion (Add to 3.1)>
    >      >     When an OSPFv2 Area Border Router (ABR) distributes information between
    >      >     connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA
    >      >     [RFC7684] including the received ELC setting.  If the received information
    >      >     is included in an LSA with an AS-wide scope, then the new LSA is not needed.
    > 
    >      Here's my suggestion for OSPFv2 ABR related text:
    > 
    >      "The ELC signaling MUST be preserved when an OSPF Area Border Router
    >      (ABR) distributes information between connected areas. To do so, ABR
    >      MUST originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including
    >      the received ELC setting."
    > 
    > Ok - I change "connected areas" to "areas" and "ABR MUST" to "an ABR MUST".
    > 
    >      Here's my suggested text for OSPFv2 ASBR case:
    > 
    >      "When an OSPF Autonomous System Boundary Router (ASBR) redistributes a
    >      prefix from another instance of OSPF or from some other protocol, it
    >      SHOULD preserve the ELC signaling for the prefix if it exists. To do so,
    >      ASBR SHOULD originate Extended Prefix Opaque LSA [RFC7684] including the
    >      ELC setting of the redistributed prefix. The flooding scope of the
    >      Extended Prefix Opaque LSA MUST match the flooding scope of the LSA that
    >      ASBR originates as a result of the redistribution. The exact mechanism
    >      used to exchange ELC between protocol instances on the ASBR is outside
    >      of the scope of this document."
    > 
    > Sure - replace "ASBR SHOULD" with "an ASBR SHOULD", "that ASBR" with "that an ASBR", and "the ASBR is" with "an ASBR is" to be consistent.
    > Also, "originate Extended" with "originate an Extended".
    > 
    > 
    > 
    >      >
    >      >
    >      > For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find
    >      > anything in rfc5340 saying that the received values should be copied
    >      > into the Inter-Area-Prefix-LSA (nor that they should not).
    >      >
    >      > Suggestion (Add to 3.2)>
    >      >     When an OSPFv3 Area Border Router (ABR) distributes information between
    >      >     connected areas, the setting of the ELC Flag in the Inter-Area-Prefix-LSA
    >      >     MUST be the same as the received value.
    > 
    >      Here's my suggestion for OSPFv3 ABR and ASBR:
    > 
    >      "The ELC signaling MUST be preserved when an OSPFv3 Area Border Router
    >      (ABR) distributes information between connected areas. The setting of
    >      the ELC Flag in the Inter-Area-Prefix-LSA [RFC5340] or in the
    >      Inter-Area-Prefix TLV [RFC8362], generated by ABR, MUST be the same as
    >      the value the ELC Flag associated with the prefix in the source area."
    > 
    > Same change - replace "connected areas" with "areas" and "by ABR" with "by an ABR".
    > 
    >      "When an OSPFv3 Autonomous System Boundary Router (ASBR) redistributes a
    >      prefix from another instance of OSPFv3 or from some other protocol, it
    >      SHOULD preserve the ELC signaling for the prefix if it exists. The
    >      setting of the ELC Flag in the AS-External-LSA [RFC5340] or in the
    >      External-Prefix TLV [RFC8362], generated by ASBR, MUST be the same as
    >      the value the ELC Flag associated with the prefix in the source domain.	
    >      The exact mechanism used to exchange ELC between protocol instances on
    >      the ASBR is outside of the scope of this document.
    > 
    > Add "NSSA-LSA" as a case. Replace "by ASBR" with "by an ASBR" and "value the ELC" with "value of the ELC".
    > 
    > Thanks,
    > Acee
    > 
    >      thanks,
    >      Peter
    > 
    > 
    >      >
    >      >
    >      >
    >      >
    >      >>> (2) If the propagation is not automatic, and the L1L2 router doesn't
    >      >>> support this specification, then what are the drawbacks/failure
    >      >>> scenarios? IOW, for multi-level operation is it a requirement that
    >      >>> the L1L2 support this specification?
    >      >>
    >      >> drawback are identical to what is mentioned in the Security
    >      >> Considerations section.
    >      >
    >      > I think that text is ok.
    >      >
    >      >
    >      > Thanks!
    >      >
    >      > Alvaro.
    >      >
    >      >
    > 
    > 
    > 
    >