Subject: Re: [nvo3] Encapsulation considerations

From: Xuxiaohu <[email-masked]>
Date: Wed, 8 Apr 2015 02:15:09 +0000

Hi Erik,

As it has said in the draft : "... We later expanded the scope somewhat to consider how the encapsulations would play with MPLS "transport", which is important because SFC and BIER seem to target being dependent of the underlying "transport"...", it would be necessary to consider the first nibble issue for those encapsulations which may be transported over MPLS. More specifically, for those encapsulations which may be directly encapsulated further with an MPLS header, they must not start with the value 4 (IPv4) or the value 6 (IPv6) in the first nibble. Otherwise, they would be mistakenly interpreted as IP payloads by transit LSRs and therefore be subjected to ECMP and potential packet misordering. 

Best regards,
Xiaohu

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: 2015年3月26日 5:01
> To: [email-masked]
> Subject: [nvo3] Encapsulation considerations
> 
> 
> I presented part of this at the most recent NVO3 interim meeting.The 
> full
12
> areas of considerations where presented at RTGWG earlier this week.
>   The draft is
>     http://datatracker.ietf.org/doc/draft-rtg-dt-encap/
>   and the slides are at
>    http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf
> 
> There is probably additional things in there to consider for NVO3, and
advice
> that can be reused to make it easier to move NVO3 forward.
> 
> Regards,
>     Erik
> 
> 
> 

_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Lucy yong <[email-masked]>
Date: Wed, 8 Apr 2015 15:43:34 +0000

This is related to my early comment. The draft needs point out transport related encapsulation and transport independent encapsulation. The considerations for two types of encapsulations have difference. 

To be able to support individual transport independent encapsulations, underlay transport needs a mechanism to distinguish carried payload. IMO: this is beyond the scope of the draft.

Lucy  

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Tuesday, April 07, 2015 9:15 PM
To: 'Erik Nordmark'; [email-masked]
Subject: Re: [nvo3] Encapsulation considerations

Hi Erik,

Best regards,
Xiaohu

12
advice

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 08 Apr 2015 17:05:00 -0700

> As it has said in the draft : "... We later expanded the scope somewhat to consider how the encapsulations would play with MPLS "transport", which is important because SFC and BIER seem to target b…

Xiaohu,
Good point.

But I couldn't tell from the emails on the BIER list whether the constraints on the first nibble value is a strict requirement in all cases, or whether it is conditional on something (and if so, what is the condition).

Once I know that answer we can definitely add some text pointing out the issue.

Thanks,
    Erik

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 9 Apr 2015 02:20:21 +0000

Hi Erik,

> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Thursday, April 09, 2015 8:05 AM
> To: Xuxiaohu; [email-masked]
> > As it has said in the draft : "... We later expanded the scope somewhat to
> consider how the encapsulations would play with MPLS "transport", which is
> important because SFC and BIER seem to target being dependent of the
> underlying "transport"...", it would be necessary to consider the first nibble
> issue for those encapsulations which may be transported over MPLS. More
> specifically, for those encapsulations which may be directly encapsulated further
> with an MPLS header, they must not start with the value 4 (IPv4) or the value 6
> (IPv6) in the first nibble. Otherwise, they would be mistakenly interpreted as IP
> payloads by transit LSRs and therefore be subjected to ECMP and potential
> packet misordering.
> 
> Xiaohu,
> Good point.
> 
> But I couldn't tell from the emails on the BIER list whether the constraints on the
> first nibble value is a strict requirement in all cases, or whether it is conditional
> on something (and if so, what is the condition).

The conditions that I have thought of include: 1) the encapsulation is sensitive to packet misordering; 2) the encapsulation may be transported over an MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of the MPLS payload to select the ECMP path.

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 9 Apr 2015 09:40:59 +0000

> From: Lucy yong
> Sent: Wednesday, April 08, 2015 11:44 PM
> To: Xuxiaohu; 'Erik Nordmark'; [email-masked]
> Subject: RE: Re: [nvo3] Encapsulation considerations
> 
> This is related to my early comment. The draft needs point out transport related
> encapsulation and transport independent encapsulation. The considerations for
> two types of encapsulations have difference.
> 
> To be able to support individual transport independent encapsulations, underlay
> transport needs a mechanism to distinguish carried payload. IMO: this is beyond
> the scope of the draft.

Logically speaking, the MPLS payload indication issue should not be addressed by the payload itself and therefore should be outside of the scope of this draft. However, due to the lack of an explicit protocol identifier field in the current MPLS architecture, this issue has to be addressed by the payload itself.

Best regards,
Xiaohu

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 09 Apr 2015 10:50:19 -0700

On 4/8/15 7:20 PM, Xuxiaohu wrote:
> Hi Erik,
>
>> But I couldn't tell from the emails on the BIER list whether the 
>> constraints on the first nibble value is a strict requirement in all 
>> cases, or whether it is conditional on something (and if so, what is 
>> the condition). 
Those are conditions when the misordering would happen. But are you 
saying that any LSR is free to use the MPLS payload (including looking 
for 4 and 6 in the first nibble) to determine whether the packet is IPv4 
and IPv6 and use what it thinks are IPv4 and IPv6 fields for ECMP purposes?

Thanks,
    Erik

---

From: Alia Atlas <[email-masked]>
Date: Thu, 9 Apr 2015 14:01:32 -0400

On Thu, Apr 9, 2015 at 1:50 PM, Erik Nordmark <[email-masked]> wrote:

>>> constraints on the first nibble value is a strict requirement in all cases,
>>> or whether it is conditional on something (and if so, what is the
>>> condition).
>>>
>> The conditions that I have thought of include: 1) the encapsulation is
>> sensitive to packet misordering; 2) the encapsulation may be transported
>> over an MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of the
>> MPLS payload to select the ECMP path.
>>
> Those are conditions when the misordering would happen. But are you saying
> that any LSR is free to use the MPLS payload (including looking for 4 and 6
> in the first nibble) to determine whether the packet is IPv4 and IPv6 and
> use what it thinks are IPv4 and IPv6 fields for ECMP purposes?

Take a quick look at RFC 4385 - which is the control word for pseudo-wires.
The short form is that a number of routers at the time peeked beneath the
label stack to figure out whether what was inside as IPv4 or IPv6 based
solely upon the first nibble.  A recommendation was made that the checksum
should also be verified, but the only equipment that I'm certain of that
did that isn't around anymore.

Also look at Section 2.4 of RFC 7325.

Alia

> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: David Allan I <[email-masked]>
Date: Thu, 9 Apr 2015 18:47:42 +0000

IMO it is simply a restriction on the first four bits of anything that can be directly encapsulated in MPLS

Otherwise, designing (for example) a version field for which IANA will have to punch holes in the assignment range does not seem like a good idea. And I’ve not been able to convince myself that this requirement has completely gone away.

Cheers
Dave

From: BIER [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Thursday, April 09, 2015 11:18 AM
To: Alia Atlas
Cc: [email-masked]; BIER; [email-masked]; [email-masked]; Erik Nordmark; Xuxiaohu
Subject: Re: [Bier] [sfc] [nvo3] Encapsulation considerations

I would venture to say that
a.      BIER misordering would be a bad thing for many applications but I do not think that the encapsulation per se misorders or not as property, it’s the way the intermediate routers are allowed to play shannigans (or seen differently, ‘heuristically’ come up with things given unclear semantics of the encaps) that causes misordering. So it is up to the encaps to give enough info so the routers in the middle do the ‘right thing’. Modulo historical problems with CW support and so on …
b.      This flavor of discussion is repeating, e.g. eVPN RFC with the CW/no CW debate which I could restore only partially and other groups now …

OK, lemme stick my (naïve ;-) head far out: why do encaps guidelines for everything that can go over PSN not mandate CW from now on? Existing gear and historical RFCs supported until they peter out and entropy labels being an orthogonal mechanism …  Or do we think the ‘heuristical DPI' is a bottomless box of band-aids ?

--- tony

On Thu, Apr 9, 2015 at 11:01 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Apr 9, 2015 at 1:50 PM, Erik Nordmark <[email-masked]<mailto:[email-masked]>> wrote:
On 4/8/15 7:20 PM, Xuxiaohu wrote:
Hi Erik,
But I couldn't tell from the emails on the BIER list whether the constraints on the first nibble value is a strict requirement in all cases, or whether it is conditional on something (and if so, what is the condition).
The conditions that I have thought of include: 1) the encapsulation is sensitive to packet misordering; 2) the encapsulation may be transported over an MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of the MPLS payload to select the ECMP path.
Those are conditions when the misordering would happen. But are you saying that any LSR is free to use the MPLS payload (including looking for 4 and 6 in the first nibble) to determine whether the packet is IPv4 and IPv6 and use what it thinks are IPv4 and IPv6 fields for ECMP purposes?

Take a quick look at RFC 4385 - which is the control word for pseudo-wires.
The short form is that a number of routers at the time peeked beneath the label stack to figure out whether what was inside as IPv4 or IPv6 based solely upon the first nibble.  A recommendation was made that the checksum should also be verified, but the only equipment that I'm certain of that did that isn't around anymore.

Alia

Thanks,
   Erik

Best regards,
Xiaohu

Thanks,
     Erik
Best regards,
Xiaohu
-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 2015年3月26日 5:01
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] Encapsulation considerations

There is probably additional things in there to consider for NVO3,
and
advice
that can be reused to make it easier to move NVO3 forward.

Regards,
      Erik

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

---

From: Ian Cox <[email-masked]>
Date: Thu, 9 Apr 2015 22:50:31 +0000

MPLS has no indication in the label stack for intermediate nodes what the underlying payload is.  To achieve better load balancing of MPLS traffic most hardware today looks to see if the first nibble is 4 or 6 then parse into the payload under the belief that it is a IPv4 or v6 packet and parse the address fields out to use in the ECMP hash.  If your defining something new please put a "next protocol" or type field in the preceding header so it clear what the next protocol is.  The 4 or 6 guess for the underlying MPLS payload being an IP packet was fine until IEEE allocated MAC addresses starting with 6. This issue is specific PWE3 packets that do not contain the control word.

Ian

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Thursday, April 09, 2015 10:50 AM
To: Xuxiaohu; Erik Nordmark; [email-masked]
Cc: [email-masked]; BIER; [email-masked]
Subject: Re: [Bier] [nvo3] Encapsulation considerations

Thanks,
    Erik

[email-masked]

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 10 Apr 2015 01:37:05 +0000

> From: Ian Cox [mailto:[email-masked]]
> Sent: Friday, April 10, 2015 6:51 AM
> To: Erik Nordmark; Xuxiaohu; [email-masked]
> Subject: RE: [Bier] [nvo3] Encapsulation considerations
> 
> MPLS has no indication in the label stack for intermediate nodes what the
> underlying payload is.  To achieve better load balancing of MPLS traffic most
> hardware today looks to see if the first nibble is 4 or 6 then parse into the
> payload under the belief that it is a IPv4 or v6 packet and parse the address
> fields out to use in the ECMP hash.  If your defining something new please put a
> "next protocol" or type field in the preceding header so it clear what the next

Is it too late to fix that flaw of the MPLS architecture (e.g., the lack of an explicit protocol id field)? Or that flaw is believed as an incomplete beauty and therefore should be preserved forever? 

Best regards,
Xiaohu

> protocol is.  The 4 or 6 guess for the underlying MPLS payload being an IP
> packet was fine until IEEE allocated MAC addresses starting with 6. This issue is
> specific PWE3 packets that do not contain the control word.

> > The conditions that I have thought of include: 1) the encapsulation is sensitive
> to packet misordering; 2) the encapsulation may be transported over an MPLS
> PSN; 3) LSRs within that MPLS PSN may use the contents of the MPLS payload to
> select the ECMP path.
> that any LSR is free to use the MPLS payload (including looking for 4 and 6 in the
> first nibble) to determine whether the packet is IPv4 and IPv6 and use what it
> thinks are IPv4 and IPv6 fields for ECMP purposes?
> 
> Thanks,
>     Erik
> 
> >
> > Best regards,
> > Xiaohu
> >
> >>>> I presented part of this at the most recent NVO3 interim
> >>>> meeting.The full
> >>> 12

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 10 Apr 2015 03:34:25 +0000

Hi Tony,

From: Tony Przygienda [mailto:[email-masked]]
Sent: Friday, April 10, 2015 2:18 AM
To: Alia Atlas
Cc: Erik Nordmark; BIER; [email-masked]; Xuxiaohu; [email-masked]; [email-masked]
Subject: Re: [Bier] [sfc] [nvo3] Encapsulation considerations

OK, lemme stick my (naïve ;-) head far out: why do encaps guidelines for everything that can go over PSN not mandate CW from now on? Existing gear and historical RFCs supported until they peter out and entropy labels being an orthogonal mechanism …  Or do we think the ‘heuristical DPI' is a bottomless box of band-aids ?
[Xiaohu] Wouldn’t it be better to insert a protocol id field than to insert a CW? The latter could only tell you the MPLS payload is not IP payload while the former could tell you what the MPLS payload is. As Eric mentioned previously in the BIER mailing-list, it’s useful for intermediate routers to know whether the MPLS payload is a BIER packet. In addition, this draft (http://tools.ietf.org/html/draft-guichard-sfc-mpls-metadata-00) also mentioned the need of determining the MPLS payload (i.e., just knowing the payload is not an IP payload is not enough). However, the approach as defined in this draft is only applicable of indicating the presence of metadata within an MPLS packet. Wouldn’t it be better to go a step further (i.e., inserting a protocol id field between the label stack and the MPLS payload)? In this way, it’s applicable of indicating whatever MPLS payloads and therefore it would not need those MPLS payloads themselves to indicate the payload types (i.e., by using the first nibble as a poor-man’s protocol id field).
Best regards,
Xiaohu
--- tony

Alia

Thanks,
   Erik

Best regards,
Xiaohu

Thanks,
     Erik
Best regards,
Xiaohu
-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 2015年3月26日 5:01
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] Encapsulation considerations

Regards,
      Erik

---

From: joel jaeggli <[email-masked]>
Date: Sat, 11 Apr 2015 11:58:26 -0700

On 4/9/15 3:50 PM, Ian Cox wrote:
> MPLS has no indication in the label stack for intermediate nodes what
> the underlying payload is.  To achieve better load balancing of MPLS
> traffic most hardware today looks to see if the first nibble is 4 or
> 6 then parse into the payload under the belief that it is a IPv4 or
> v6 packet and parse the address fields out to use in the ECMP hash.

Some of them also use the TOS or DSCP bits as part of the hashkey with
the additional ensuing entertainment value that provides.

> If your defining something new please put a "next protocol" or type
> field in the preceding header so it clear what the next protocol is.
> The 4 or 6 guess for the underlying MPLS payload being an IP packet
> was fine until IEEE allocated MAC addresses starting with 6. This
> issue is specific PWE3 packets that do not contain the control word.
> 
> 
> Ian
> 
> -----Original Message----- From: BIER [mailto:[email-masked]]
> On Behalf Of Erik Nordmark Sent: Thursday, April 09, 2015 10:50 AM 
> To: Xuxiaohu; Erik Nordmark; [email-masked] Cc: [email-masked]; BIER;
> [email-masked] Subject: Re: [Bier] [nvo3] Encapsulation considerations
> 
>>>  constraints on the first nibble value is a strict requirement in
>>> all cases, or whether it is conditional on something (and if so,
>>> what is the condition).
>> The conditions that I have thought of include: 1) the encapsulation
>> is sensitive to packet misordering; 2) the encapsulation may be
>> transported over an MPLS PSN; 3) LSRs within that MPLS PSN may use
>> the contents of the MPLS payload to select the ECMP path.
> saying that any LSR is free to use the MPLS payload (including
> looking for 4 and 6 in the first nibble) to determine whether the
> packet is IPv4 and IPv6 and use what it thinks are IPv4 and IPv6
> fields for ECMP purposes?
> 
> Thanks, Erik
> 
>> 
>> Best regards, Xiaohu
>> 
>>> Thanks, Erik
>>>> Best regards, Xiaohu
>>>>> -----Original Message----- From: Erik Nordmark
>>>>> [mailto:[email-masked]] Sent: 2015年3月26日 5:01 To:
>>>>> [email-masked] Subject: [nvo3] Encapsulation considerations
>>>>> 
>>>>> 
>>>>> areas of considerations where presented at RTGWG earlier this
>>>>> week. The draft is 
>>>>> http://datatracker.ietf.org/doc/draft-rtg-dt-encap/ and the
>>>>> slides are at 
>>>>> Regards, Erik
>>>> _______________________________________________ nvo3 mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/nvo3
>>>> 
>> 
> 
> _______________________________________________ BIER mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/bier 
> _______________________________________________ nvo3 mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/nvo3
>