Subject: [mpls] draft-zzhang-intarea-generic-delivery-functions

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 12 Jan 2021 14:27:28 +0000

Hi,

I just posted https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/.

The initial version was posted to the tsvwg (https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00). After discussions/feedback we are re-homing it to intarea wg. This new version also contains quite some changes based on the comments and feedback that we received (special thanks to Stewart).

Comments and suggestions are appreciated.

Thanks.
Jeffrey

Juniper Business Use Only

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 12 Jan 2021 14:59:16 +0000

Thank you Jeffery

Please see the note that I sent about iOAM who also want to sit after BoS … and both of you want the same space that PALS and DetNet is already using.

We plan to have a joint session on this hosted by PALS at the next IETF, but I think we also need to include the iOAM people.

This has scope to get very messy as we find new candidates for BoS metadata so we really need to take a holistic position to ensure the future health the MPLS protocol.

- Stewart

> On 12 Jan 2021, at 14:27, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Yangfan (IP Standard)" <[email-masked]>
Date: Mon, 18 Jan 2021 10:24:18 +0000

Hi authors,

The idea of a shim layer to provide the generic delivery function is interesting. I have 3 questions for clarification.

1. The draft request a new number of Internet Protocol Number registry for GDFH, I assume in this case, GDFH is used together with IP header. I wonder what the benefit is to have this generic header other than directly specifying the functionality as the next header? 
2. If the GDFH is used with MPLS, what is the difference compared to G-ACh? 
3. If you suggest to use one uniform encapsulation in Figure 2 for IP/MPLS/BIER, starting with 0000 would make sense when it is encapsulated in MPLS, but seems unnecessary in IP. Because in IP, usually 5-tuple is used for hashing algorithm. First 4 zeroes don't help to avoid the hashing problem. 

Best regards, 
Fan 

-----邮件原件-----
发件人: mpls [mailto:[email-masked]] 代表 Jeffrey (Zhaohui) Zhang
发送时间: 2021年1月12日 22:27
收件人: [email-masked]; mpls <[email-masked]>; [email-masked]
抄送: Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>
主题: [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi,

Thanks.
Jeffrey

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

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 19 Jan 2021 15:57:19 -0500

Hi Stewart,
Thanks for your comments. If we have a mechanism like following, does that
address the issue?

   1. IOAM header is part of the MPLS encapsulation, any other control word
   is added after the IOAM header in the data packet.
   2. The transit nodes can process the IOAM data field(s) after the EOS in
   data packets as it is proposed.
   3. The decapsulating node removes the MPLS encapsulation including the
   IOAM header and then processes the other control word following it.

   0                   1                   2                   3

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | IOAM Indicator Label                  | TC  |1|  TTL          |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+

   |0 0 0 1|Version| Reserved      | IOAM G-ACh                    |  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |

   | Reserved      | Block Number  | IOAM-OPT-Type |IOAM HDR Length|  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  I

   |                                                               |  O

   |                                                               |  A

   ~                 IOAM Option and Data Space                    ~  M

   |                                                               |  |

   |                                                               |  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+

   |0 0 0 0| Rsved | This Header   | Header Length | Next Header   |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ~              Variable field per “This header”                 ~

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                                                               |

   |                                                               |

   ~                 Payload Packet                                ~

   |                                                               |

   |                                                               |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks,
Rakesh

On Tue, Jan 12, 2021 at 10:00 AM Stewart Bryant <[email-masked]>
wrote:

> Thank you Jeffery
>
> Please see the note that I sent about iOAM who also want to sit after BoS
> … and both of you want the same space that PALS and DetNet is already using.
>
> We plan to have a joint session on this hosted by PALS at the next IETF,
> but I think we also need to include the iOAM people.
>
> This has scope to get very messy as we find new candidates for BoS
> metadata so we really need to take a holistic position to ensure the future
> health the MPLS protocol.
>
> - Stewart
>
>
> > I just posted
> https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/
> .
> >
> > The initial version was posted to the tsvwg (
> https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00).
> After discussions/feedback we are re-homing it to intarea wg. This new
> version also contains quite some changes based on the comments and feedback
> that we received (special thanks to Stewart).
> >

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 20 Jan 2021 07:23:04 +0000

A generic mechanism for multiple headers is described in the following draft:
https://www.ietf.org/archive/id/draft-song-mpls-extension-header-02.txt

Tianran

From: mpls [mailto:[email-masked]] On Behalf Of Rakesh Gandhi
Sent: Wednesday, January 20, 2021 4:57 AM
To: Stewart Bryant <[email-masked]>
Cc: mpls <[email-masked]>; [email-masked]; <[email-masked]> <[email-masked]>; Ronald Bonica <[email-masked]>; Kireeti Kompella <[email-masked]>; [email-masked]
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi Stewart,
Thanks for your comments. If we have a mechanism like following, does that address the issue?

  1.  IOAM header is part of the MPLS encapsulation, any other control word is added after the IOAM header in the data packet.
  2.  The transit nodes can process the IOAM data field(s) after the EOS in data packets as it is proposed.
  3.  The decapsulating node removes the MPLS encapsulation including the IOAM header and then processes the other control word following it.

   0                   1                   2                   3

   |                                                               |  O

   |                                                               |  A

   |                                                               |  |

   |                                                               |  |

   |                                                               |

   |                                                               |

   ~                 Payload Packet                                ~

   |                                                               |

   |                                                               |

Thanks,
Rakesh

On Tue, Jan 12, 2021 at 10:00 AM Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Jeffery

- Stewart

> On 12 Jan 2021, at 14:27, Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>

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