Subject: [Bier] FW: New Version Notification for draft-zzhang-mpls-icmp-bier-00.txt

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 11 Jun 2015 19:58:44 +0000

Hi,

Please review and comment on this draft:

https://www.ietf.org/internet-drafts/draft-zzhang-mpls-icmp-bier-00.txt

Summary:

   RFC3032 specifies that an LSR may generate ICMP messages if the
   payload is IPv4 or IPv6.  Normally the ICMP messages are label
   switched using the original label stack, and the egress LSR will then
   forward the the messages to the source of the packet.

   This document specifies an optional extension to generate ICMP
   messages for BIER packets transported over LSPs.

         BFIR --- BFR1  --- non-BFR1 --- non-BFR2 --- BFR2 --- BFER
                   \...........tunnel................../
                              ^
                              |
                              ttl-expiration on non-BFR1;
                              generated ICMP message label switched to,
                              and processed by BFR2

Thanks!
Jeffrey

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 11, 2015 3:20 PM
To: Jeffrey (Zhaohui) Zhang; Jeffrey (Zhaohui) Zhang
Subject: New Version Notification for draft-zzhang-mpls-icmp-bier-00.txt

A new version of I-D, draft-zzhang-mpls-icmp-bier-00.txt
has been successfully submitted by Zhaohui Zhang and posted to the
IETF repository.

Name:		draft-zzhang-mpls-icmp-bier
Revision:	00
Title:		MPLS ICMP for BIER Payload
Document date:	2015-06-11
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-zzhang-mpls-icmp-bier-00.txt
Status:         https://datatracker.ietf.org/doc/draft-zzhang-mpls-icmp-bier/
Htmlized:       https://tools.ietf.org/html/draft-zzhang-mpls-icmp-bier-00

Abstract:
   This document specifies an optional extension to generate ICMP
   messages for BIER packets transported over LSPs.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 23 Jun 2015 10:27:04 +0200

Hi Jeffrey,

Looks good, nice idea, well written!

One comment, the below text took me a while to parse, I think it would help the reader to add a picture to indicate the ‘inner’ labels you are referring to.

   For a true BIER
   packet, the next inner most label is advertised by the same BFR that
   advertised the inner most label, so the original label stack minus
   the inner most label should get the generated ICMP/ICMPv6 message to
   the right place for further processing.

Thx,

Ice.

> On 11 Jun 2015, at 21:58, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Tue, 23 Jun 2015 14:01:04 +0000

Hi Jeff,

I read the draft and it appears that the transit non-BFR node may need an
upgrade to support this feature. If it requires an upgrade, I think an
Operator could choose to upgrade to something that supports BIER. Or did
you had other use case in mind where the CP only will be upgraded?.

TO add to what Ice mentioned below, I assume, by ³next inner most label²
you meant BIER label advertised by BFR2 in the draft topology?. If so, I
think it is not necessarily the same BFR that assigns the inner most
label. I assume you mean the same BFR will terminate the LSP?.

Section 2 mentions that the "ICMP message processing² is outside the scope
of the draft. We may need to further define on how the BFR (processing the
ICMP message) interpret the details from ICMP payload and generate the
BIER OAM Echo Reply. This is required so that the Initiator receives the
response for the right senders handle, seq. number etc.

Regards,
Nagendra

On 6/23/15, 4:27 AM, "IJsbrand Wijnands (iwijnand)" <[email-masked]> wrote:

>One comment, the below text took me a while to parse, I think it would
>help the reader to add a picture to indicate the Œinner¹ labels you are
>referring to.
>
>   For a true BIER
>> URL:            
>> Status:         
>>https://datatracker.ietf.org/doc/draft-zzhang-mpls-icmp-bier/
>> Htmlized:       
>>https://tools.ietf.org/html/draft-zzhang-mpls-icmp-bier-00
>> 
>> 
>> Abstract:

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 23 Jun 2015 14:05:16 +0000

Ice,

Thanks for your comments!

> >                              generated ICMP message label switched to,

When the TTL expires on non-BFR1, the label stack is (tunnel label, bier label). The inner most label is the bier label (advertised by BFR2), and the next inner most label is the tunnel label, which is NOT (necessarily) advertised by BFR2. It is however the label for the tunnel terminating at BFR2, and will get the generated ICMP message to BFR2 (when it arrives at BFR2, the tunnel label will have been swapped to a label advertised by BFR2, which could be implicit null).

I will update the draft with the correction and clarification.

Thanks.
Jeffrey

> From: IJsbrand Wijnands [mailto:[email-masked]]
> Sent: Tuesday, June 23, 2015 4:27 AM
> To: Jeffrey (Zhaohui) Zhang
> Cc: BIER
> Subject: Re: [Bier] New Version Notification for draft-zzhang-mpls-icmp-
> bier-00.txt
> 
> Hi Jeffrey,
> 
> help the reader to add a picture to indicate the ‘inner’ labels you are
> referring to.
> 
>    For a true BIER
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> tools.ietf.org.
> >
> > The IETF Secretariat
> >

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 23 Jun 2015 14:18:14 +0000

Nagendra,

> From: Nagendra Kumar Nainar (naikumar) [mailto:[email-masked]]
> Sent: Tuesday, June 23, 2015 10:01 AM
> To: IJsbrand Wijnands (iwijnand); Jeffrey (Zhaohui) Zhang
> Cc: BIER; Carlos Pignataro (cpignata)
> I read the draft and it appears that the transit non-BFR node may need
> an upgrade to support this feature. If it requires an upgrade, I think
> an Operator could choose to upgrade to something that supports BIER. Or
> did you had other use case in mind where the CP only will be upgraded?.

Yes the transit routers will need an upgrade for a little bit more intelligence, w/o being required to parse the BIER encapsulation.

Even if it is a router that fully supports BIER, it is better to leave the processing to the BFR at the tunnel egress. In theory, the LSR and the BFR could even be in different bier sub-domains.

> label. I assume you mean the same BFR will terminate the LSP?.

There is indeed a wording problem (see my reply to Ice earlier).

If you consider a more complicated situation, the transport tunnel itself could be stacked on top of another one, so the *next* inner *most* label is not necessarily for the LSP on which the TTL expired. However, the label stack minus the inner most label (bier label) should get the packet to the BFR.

> 
> Section 2 mentions that the "ICMP message processing² is outside the
> scope of the draft. We may need to further define on how the BFR
> (processing the ICMP message) interpret the details from ICMP payload
> and generate the BIER OAM Echo Reply. This is required so that the
> Initiator receives the response for the right senders handle, seq.
> number etc.

Exactly. An additional draft, e.g. the BIER OAM draft, should address that.

Jeffrey

> >> On 11 Jun 2015, at 21:58, Jeffrey (Zhaohui) Zhang
> >><[email-masked]>
> >>wrote:
> >>
> >> Hi,
> >>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 30 Jun 2015 19:14:15 +0000

A new revision has been submitted to for the clarification/correction mentioned below.

URL:            https://www.ietf.org/internet-drafts/draft-zzhang-mpls-icmp-bier-01.txt
Status:         https://datatracker.ietf.org/doc/draft-zzhang-mpls-icmp-bier/
Htmlized:       https://tools.ietf.org/html/draft-zzhang-mpls-icmp-bier-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-zzhang-mpls-icmp-bier-01

Thanks.
Jeffrey

> From: Jeffrey (Zhaohui) Zhang
> Sent: Tuesday, June 23, 2015 10:05 AM
> To: 'IJsbrand Wijnands'
> Cc: BIER
> Subject: RE: [Bier] New Version Notification for draft-zzhang-mpls-icmp-
> bier-00.txt
> 
> Ice,
> 
> When the TTL expires on non-BFR1, the label stack is (tunnel label, bier
> label). The inner most label is the bier label (advertised by BFR2), and
> the next inner most label is the tunnel label, which is NOT (necessarily)
> advertised by BFR2. It is however the label for the tunnel terminating
> at BFR2, and will get the generated ICMP message to BFR2 (when it
> arrives at BFR2, the tunnel label will have been swapped to a label
> advertised by BFR2, which could be implicit null).
> 
> > Subject: Re: [Bier] New Version Notification for
> > draft-zzhang-mpls-icmp- bier-00.txt
> >
> > Hi Jeffrey,
> >
> > help the reader to add a picture to indicate the ‘inner’ labels you
> > are referring to.
> >
> >    For a true BIER