Re: [mpls] [Bier] [sfc] [nvo3] Encapsulation considerations

[Xuxiaohu <[e-mail]>]

Hi Tony,

From: Tony Przygienda [mailto:[e-mail]]
Sent: Friday, April 10, 2015 2:18 AM
To: Alia Atlas
Cc: Erik Nordmark; BIER; [e-mail]; Xuxiaohu; [e-mail]; [e-mail]
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 ?
[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

On Thu, Apr 9, 2015 at 11:01 AM, Alia Atlas <[e-mail]<mailto:[e-mail]>> wrote:
On Thu, Apr 9, 2015 at 1:50 PM, Erik Nordmark <[e-mail]<mailto:[e-mail]>> 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.

Also look at Section 2.4 of RFC 7325.

Alia


Thanks,
   Erik

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

Thanks,
     Erik
Best regards,
Xiaohu
-----Original Message-----
From: Erik Nordmark [mailto:[e-mail]<mailto:[e-mail]>]
Sent: 2015年3月26日 5:01
To: [e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/nvo3


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


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