Subject: RE: response to ITU-T SG13

From: "David Allan"<[email-masked]>
Date: Mon, 15 Apr 2002 16:39:53 -0400

Hi Loa:

Thanks for having done due dilligence on the PIM reference. The rest of my
comments are directed towards the list in general...

Last time I looked, MPLS multicast was a completely separate protocol
potentially employing a separate forwarding plane/fabric (having a different
PID and label space which by definition would have to be disjoint from the
unicast MPLS space). 

I politely flagged this one as I think it is a bit of a stretch to ask the
ITU to comment on the effects of Y.1711 on stuff that does not exist and has
not yet been specified. This is in addition to asking it's impact on
proprietary implementations where to date there has been under-specification
(the reserved labels issue with PHP and multi-link load sharing have been
raised so far), as well as what protocol extensions may be required to
synchronize using this tool (which George/co-chair noted was a trivial issue
on the list back on March 21st).

I'm really curious to know how any reasonable response to the liaison will
be/can be interpreted. What if the techology is OK but study group 13's
crystal ball is found wanting? Would that be a good reason to hold things
up...I don't think so.

cheers
Dave

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Monday, April 15, 2002 10:35 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Scott Bradner; [email-masked]
> Subject: Re: response to ITU-T SG13
> 
> 
> All,
> 
> did read this before it was sent. I thought that PIM came in via the
> mpls multicast framework, just now processed by the IESG to the
> rfc-editor. See e.g. page 18 in the framework:
> 
> "a) Multicast routing messages: protocols as PIM-SM and CBT have
>     explicit Join messages which could carry the label mappings.  This
>     approach is described in [FARI].  When different multicast routing
>     protocols are deployed, an extension to each of these 
> protocols has
>     to be defined."
> 
> But I might be wrong. The [FARI] did not go anywhere did it?
> 
> /loa
> 
> David Allan wrote:
> 
> > Hi Scott:
> > 
> > I think readability would be enhanced if the third paragraph was 
> > deleted..."Since manual configuration .... before Y.1711 
> would be seen 
> > as a complete solution."....The third para discusses if changes to 
> > CR-LDP and RSVP are expected and a few paragraphs later the 
> question is 
> > enlarged to include LDP, PIM and BGP.
> > 
> > I'll plead ignorance, but I'm not sure why PIM is on the list...?
> > 
> > cheers
> > Dave
> > 
> > 
> >  > -----Original Message-----
> >  > From: Scott Bradner [mailto:[email-masked]]
> >  > Sent: Friday, April 12, 2002 4:45 PM
> >  > To: [email-masked]
> >  > Subject: response to ITU-T SG13
> >  >
> >  >
> >  >
> >  > This is the response to
> >  > http://www.ietf.org/IESG/LIAISON/ITU-SG13-MPLS-OAM.txt
> >  > that was discussed during the MPLS session in Minneapolis
> >  > that I plan to
> >  > send early next week unless the WG has a problem with that.
> >  > (Thanks to George for the draft that this is based on)
> >  >
> >  > Scott
> >  >
> >  > ---------
> >  >
> >  > SOURCE: IETF Sub-IP Area - Scott Bradner, Area co-Director
> >  > TITLE: Response to "Communication on the status of the 
> request on the
> >  >   assignment of a reserved label value for MPLS OAM packet
> >  > identification"
> >  >
> >  > The MPLS working group discussed SG 13's request for the
> >  > assignment of a
> >  > reserved label value for MPLS OAM packet identification
> >  > (draft-ohta-mpls-label-value-01.txt) during the MPLS session
> >  > during the
> >  > recent IETF meeting in Minneapolis.  There was some
> >  > disagreement during the
> >  > discussion about the long term implications  of the IETF 
> granting this
> >  > request.
> >  >
> >  > During the discussion it was noted that there are a number of
> >  > references to
> >  > modifications to IETF protocols in Y.1711.  In 
> particular, Section 6.1
> >  > states, "Ideally this should be done automatically  via LSP
> >  > signaling at
> >  > LSP set-up time (e.g. via a CR-LDP or RSVP  control-plane
> >  > mechanism), but
> >  > it could also be configured manually.   The mechanism for
> >  > achieving this
> >  > configuration is outside the scope of this Recommendation."
> >  >
> >  > Since manual configuration is probably not an option for
> >  > anything beyond a
> >  > very limited deployment the implication is that the ITU will
> >  > require the
> >  > IETF to change CR-LDP and RSVP before Y.1711 would be seen as
> >  > a complete
> >  > solution.
> >  >
> >  > Also in section 6.3, Forward Defect Indication, the following
> >  > text may be
> >  > read as indicating an assumption of future changes in  
> IETF protocols
> >  > dealing with LSP signaling.
> >  >
> >  > "It is important that the LSP sink point knows (for the
> >  > duration that the
> >  > LSP is in service) any server->client LSP label mappings 
> that were in
> >  > existence prior to the defect.  Although the exact means for
> >  > achieving this
> >  > are outside the scope of this Recommendation, some examples
> >  > of how these
> >  > server-> client layer label mappings could be configured are
> >  > as follows:
> >  >    o manually, via the NMS say; 
> >  >    o automatically on LSP set-up via extensions to LSP 
> signaling ..."
> >  >
> >  > In order to understand the possible consequences of 
> allocating an MPLS
> >  > codepoint in response to the request in 
> >  > draft-ohta-mpls-label-value-01.txt
> >  > the MPLS working group would like to understand the full
> >  > scope and extent
> >  > of the modifications that SG13 may be assuming to other IETF
> >  > protocols,
> >  > including LDP, CR-LDP, RSVP, PIM and BGP.
> >  >
> >  > A further concern is the impact on the MPLS forwarding plane
> >  > as currently
> >  > defined.  In certain points in a MPLS network, based on an
> >  > incoming label,
> >  > the label is removed and the packet is forwarded with no
> >  > further inspection
> >  > of subsequent headers (be it another MPLS label or some 
> other header).
> >  > Y.1711 seems to imply that the above behavior would not
> >  > satisfy Y.1711.
> >  > Specifically, there are some cases where Y.1711 would 
> expect a network
> >  > element to intercept an OAM packet. This raises issues 
> of backward
> >  > compatibility with existing MPLS systems and ASICs. 
> >  >
> >  > The MPLS working group would like to understand if Y.1711 assumes
> >  > functionally that could not be supported by simply changing
> >  > software in
> >  > existing MPLS implementations.
> >  >
> >  > 
> >  >
> > 
> 
> 
> -- 
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> Råsundavägen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           [email-masked]
> WWW             www.utfors.se
> 
>

---

From: Eric Rosen <[email-masked]>
Date: Tue, 16 Apr 2002 10:05:46 -0400

David> I politely flagged  this one as I think  it is a bit of  a stretch to
David> ask the  ITU to comment on the  effects of Y.1711 on  stuff that does
David> not exist  and has  not yet  been specified. This  is in  addition to
David> asking it's impact on proprietary implementations where to date there
David> has been under-specification 

It is perfectly reasonable to ask whether the ITU foresees extending the OAM
mechanisms in such a  way as to impact any of the  existing or even foreseen
label  distribution and/or  routing protocols  and mechanisms.   It  is also
perfectly reasonable to ask about the impact of those mechanisms on existing
deployments and implementations.  One can of course offer a bunch of trumped
up excuses  for not wanting to answer  the question, but perhaps  that is an
answer in itself.

---

From: Eric Rosen <[email-masked]>
Date: Tue, 16 Apr 2002 10:05:46 -0400