Re: [Bier] draft-ietf-bier-ipv6-requirements-09

[[e-mail]]

Hi Gyan,






We can't come to the conclusion that there is no technical issues within 6MAN regarding the solutions you mentioned. I raised a thread (Extension Header processing rules) in 6MAN and want to hear suggestions from more 6MAN experts, and Bob, Tom gava fair advice.





Yes, in theory, you can do anything with DOH (in your case you want to let DOH have a behavior like Routing Header). But, the fact is that specific Extension Header is defined for specifc purpose. 


In your solution that you mentioned, you want to:


1) Update DA again and again by the information get from DOH before the packet reach the final destination.


2) When DOH is finished to be processed at the node that matched DA, the Next Header is not continued to be processed.


I don't see the above two strange features in the existing Options defined for DOH. See https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2


0x04	00	0	00100	Tunnel Encapsulation Limit	[RFC2473]

0xC9	11	0	01001	Home Address	[RFC6275]

0x8B	10	0	01011	ILNP Nonce	[RFC6744]

0x8C	10	0	01100	Line-Identification Option	[RFC6788]

0x0F	00	0	01111	Performance and Diagnostic Metrics (PDM)	[RFC8250]

0x11	00	0	10001	IOAM 	[draft-ietf-ippm-ioam-ipv6-options]

0x31	00	1	10001	IOAM    [draft-ietf-ippm-ioam-ipv6-options]






There are other technical issues of course.


For example, using SRv6 SID in the DA field of BIER IPv6 packet to indicate there are BIER information Option in DOH is superfluous. IMO, Option Type itself can do that, and there maybe more options in single DOH. So far I have not seen an SRv6 SID is used to indicate the decapsulation things that Next Header field can be done, please refer to any endpoint behaviors defined in SRv6 PGM. Please also note that in RFC8754 for an IPv6 packet with SRH, it is possible a normal IPv6 address is contained in DA when Segment Left is 0. That means the DA itself can not give you any indication to decapsulate the packet. Depending on Next Header is standard behavior.



BTW, please take care ICMP issues related with SA.






Regards,


PSF













原始邮件



发件人：GyanMishra
收件人：Alvaro Retana;BIER WG;Greg Shepherd;Jeffrey (Zhaohui) Zhang;Tony Przygienda;draft-ietf-bier-ipv6-requirements;张征00007940;
日 期 ：2020年11月18日 23:14
主 题 ：[Bier] draft-ietf-bier-ipv6-requirements-09


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

All

I would like to thank the Greg, Tony and Alvaro on their pointers and guidance this morning to help move the ball forward with the requirements draft.


What I heard from Greg which rang out loud and clear and I mentioned to the requirements authors that today we have BIER MPLS where the BIER header is encoded into MPLS label stack layer 2 1/2 and we also have non MPLS BIER Ethernet ether type 0xAB37.  



So why do we need non MPLS BIER encapsulation in an IPV6 environment as that IPv6 environment can be supported by non MPLS BIER Ethernet.  The case and point here is that eventually just as ATM and Frame Relay now live in the technology graveyard so will at some point in time as SRv6 matures will become the end all be all “core transport” mechanism for all operators.  So that being said we need a another encapsulation method to carry BIER , and per RFC 8296 that gap is filled with Non MPLS BIER Ethernet encapsulation today which will work for future SRv6 transport once MPLS goes by the wayside.


At the beginning of the presentation Greg corrected me and stated that that after the BIERin6 independent model draft was published, that the requirement draft came about to build a set of requirements as to the “why” we need BIER to work in a non MPLS BIER in an IPv6 environment when we already have the BIER Ethernet encapsulation that fits the bill and works.  


So that’s the million $$ question we are trying to solve here with the requirements draft.



As for the IPV6 6MAN questions, I was brought on board by Mike McBride as the IPv6 SME as well as multicast SME - but point being member of 6MAN for many years so a go between liaison with 6MAN related to any questions regarding following the IPV6 specification for extension header usage per RFC 8200.  Both solutions drafts had been reviewed by myself and 6MAN and no technical issues were found regarding the solutions.



Alvaro mentioned as far as the list of requirements that they were fairly basic but maybe needed some more meat behind it such as the “support various L2 link types” but we did not specify.  In previous versions we stated L2 agnostic and then switched to various but being vague on which L2.  Alvaro also mentioned why OAM should be a requirement.  We may want to add a sentence on justification as to why we picked BIER IPv6 requirements as required versus optional.


We need to add some more meat in the introduction or maybe even a separate section as to what gap is being filled by non MPLS BIER in IPv6 environment using IPv6 encapsulation and encoding the BIER header versus Non MPLS BIER Ethernet.  Also maybe use the requirements section to see if a new requirement that maybe a gap that is not covered by non MPLS BIER Ethernet that can be covered by non MPLS BIER in an IPv6 environment.



At the end of the call when we rolled through the last two drafts and went into overtime I heard the ask for call for adoption for BIERin6 independent model.



https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/




I would not think we are ready to adopt any non MPLS BIER in IPV6 environment solution if we still do not have the requirements set as to the gap that is being filed and problem being solved that cannot be done today with non MPLS BIER Ethernet.


The flip side of the comment above is that if we are ready to adopt and we decided we can skip answering the “why” questions, so then do we need the requirements draft at all if that’s the case as we have made the decision to go with a single solution and are closing the door on any other options.  If the latter then we hang tight on any adoption of any solution and wait till the requirements draft is completed and adopted followed by moving forward with adopting any solutions.



Kind Regards 


Gyan


-- 













Gyan Mishra


Network Solutions Architect 


M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD