Re: [mpls] Mirja Kühlewind's Discuss on draft-ietf-mpls-sr-over-ip-03: (with DISCUSS)

["Adrian Farrel" <[e-mail]>]

Thanks Mirja,

>>> 1) Given section 3.1, the following drafts all seems that they
>>> should be normative references: ietf-isis-encapsulation-cap,
>>> ietf-ospf-encapsulation-cap, ietf-ospf-segment-routing-extensions,
>>> ietf-isis-segment-routing-extensions
>> 
>> Well, that wasn't the intention. It is meant to be an example of
>> how the forwarding entries are constructed.
>> 
>> As it says at the top of Section 3...
>>   Note that the examples in
>>   Section 3.1 and Section 3.2 assume that OSPF or ISIS is enabled: in
>>   fact, other mechanisms of discovery and advertisement could be used
>>   including other routing protocols (such as BGP) or a central
>>   controller.
>> 
>> We could be more explicit in section 3.1 so that, for example...
>> 
>> OLD
>>   o  The Segment Routing Global Block (SRGB) is defined in [RFC8402].
>>      Router E is SR-MPLS capable, so it advertises an SRGB as described
>>      in [I-D.ietf-ospf-segment-routing-extensions] and
>>      [I-D.ietf-isis-segment-routing-extensions].
>> NEW
>>   o  The Segment Routing Global Block (SRGB) is defined in [RFC8402].
>>      Router E is SR-MPLS capable, so it advertises an SRGB to the other
>>      SR-MPLS capable routers.  If an IGP is in use then Router E behaves
>>      as described in [I-D.ietf-ospf-segment-routing-extensions] and
>>      [I-D.ietf-isis-segment-routing-extensions], but other mechanisms
>>      Could be applied.
>> END
>> 
>> We'd need to make similar changes throughout the section.
>> 
>> Would such changes be enough for you?
>
> It still sounds to me that these document are basically a must read 
> to understand the full picture. Do you think it would be a problem
> or the wrong thing to make these reference normative?
>
> However, your wording change makes it definitely more clear that
> this is only one example. If the wg and responsible ADs think, it’s
> the right thing to do to leave the reference informative, I will clear
> my discuss.

I was worried about the rate of progress of SR documents. There has been a tendency for them to travel a little slowly.

It looks like these documents have all now progressed far enough, but they are caught up in a deadly cluster of missing references (cluster 340). We'll have a look through the cluster to see how dangerous it is and make normative references where we can.

>>> 2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN
>>> field and eventually RFC2983 for DSCP.
>> 
>> That's good. Thanks. It gives us...
>> 
>>            <t hangText="IP Header Fields:">When encapsulating an MPLS
>>            packet in UDP, the resulting packet is further encapsulated in
>>            IP for transmission. IPv4 or IPv6 may be used according to the
>>            capabilities of the network. The address fields are set as
>>            described in <xref target="usecases"/>. The other IP header
>>            fields (such as the ECN field <xref target="RFC6040"/>, the DSCP 
>>            code point <xref target="RFC2983"/>, or IPv6 Flow Label) on each
>>            UDP-encapsulated segment SHOULD be configurable according to the
>>            operator&apos;s policy: they may be copied from the header of the
>>            incoming packet; they may be promoted from the header of the
>>            payload packet; they may be set according to instructions
>>            programmed to be associated with the SID; or they may be
>>            configured dependent on the outgoing interface and payload.</t>
>
> Yes, thanks!

Perfect. It's in my working copy.

Best,
Adrian