Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)

Here is a resend. I screwed the From address in the last mail.
Der-Hwa 

------- Forwarded Message

> 
> Well, in theory this shouldn't cause any interop problems because
> no matter what approach it has chosen itself, an implementation has to
> be prepared to deal with a bandwidth decrease via a simple change in

An implementation has to be prepared to deal with changes in ERO, RRO, 
Label Object, Label Request Object, SessionAttribute without
requiring a new LSP-ID. In fact, an implementation should be prepared
that most RSVP objects may change on-the-fly, and react accordingly.

None of this is specified in rfc2205 and rfc3209, and most implementations
do a good job on it today. Why is bandwidth decrease so uniquely different?

> the tspec or via a reroute (new LSP-ID). In practice, it apparently
> has caused interop problems...
> 
> I'm only familiar with three implementations, two of them use the
> reroute method and one just changes the tspec. Because reroute
> is the safer method that is guaranteed to work, I'm with JP here

There are deployed implementations on live networks today, it is
way beyond the stage of being 'safer'. 

It is perhaps more appropriate to ask what is the technical reason that a 

RE: RE: Latest MPLS Ping draft...

RESEND: RE: Latest MPLS Ping draft...

Resend: apologies for last formatting

Hi Kireeti: 
Don't know if we closed on a few items...or just got busy  
1) TTL decrements to zero - if LSP ping not on top label (uniform model),
discard message (Y/N) 
2) Sequence number - repeated issue of same or always monotonically increase

3) Definition of FEC - if different from MPLSARCH then define? 
cheers 
Dave 

LSP Ping Draft Comment/Question

	
	Hi,

	One question about the LSP Ping draft after reading
it again yesterday. It appears that implementation of all of
the different modes of operation are mandatory, since there is
no mention of minimum level(s) of implementation for conformance
with the standard.  I personally do not feel that it is a good idea to require
that the entire draft be implemented to comply, since some of the alternate
modes of operation might either not be supported by certain
devices, or simply too much work to implement for some time
for a vendor.

	--Tom
Success is relative; the more success, the more relatives. -Anonymous

Re: Questions on LDP MIB v9

mpls wg document status - update

All,

at the last IESG meeting "a pile of mpls docs were discussed". This
is a short update on doc status.

We have five new documents approved for publishing as proposed standard

   <draft-ietf-mpls-ldp-ft-06.txt>
   <draft-ietf-mpls-ldp-restart-06.txt>
   <draft-ietf-mpls-lsp-hierarchy-08.txt>
   <draft-ietf-mpls-rsvp-unnum-08.txt>

And one as an informational RFC
draft-ietf-mpls-recovery-frmwrk-08.txt

All the documents will shortly show up on the RFC-editors queue.

Please join us in congratulating all the authors who have done
a great job!

One document were returned to the working group to be coordinated
with a parallel work in the idr wg

   <draft-ietf-mpls-bgp-mpls-restart-02.txt>

Contact has been taken with idr wg chair to see if there is anything
that needs/could to be done from the mpls to speed up the process.

One document were returned to the authors (i.e. the mpls wg chairs :) )
for "word tweaking".

   <draft-andersson-mpls-sig-decision-01.txt>

Plan to "tweak" tomorrow, and hopefully the doc is back on the IESG
agenda shortly.

Further information at:

http://urax.utfors.net/~loa/MPLS_WG_Drafts.htm

Loa and George.

--

-- 
     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           loa.andersson <at> utfors.se
     WWW             www.utfors.se

RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt

> >Although, it may be necessary to clarify this a tad, I don't
> >believe there is a conflict.  Perhaps, this description
> >should simply state:
> >For RSVP, the MplsLSPId is the "LSP ID" as defined in RFC3209.
>
>Then for RSVP-TE, what's the sense to define LSP ID in XC table? This two
>bytes LSPID can't identify an unique LSP. Don't need to mention transit
>node, even within single ingress node it's not unique right?

         The MPLS-LSR MIB has to (and does) work for all existing
applications of MPLS.  Because of this there may be overlaps between
the application-specific MIBs so that the MIB can work on its
own. My recollection is that this is probably one of the only cases of
that.  In defense of the redundant information, this information is
useful on LSRs where the MPLS-TE MIB might not be implemented
since one can still see the LSP for the tunnel.

         --Tom

Success is relative; the more success, the more relatives. -Anonymous

RE: mpls wg document status - update

Loa, I am really impressed with your efforts to keep us (ADs)
and the WG so well informed of the status of documents in the
WG. I wish all WG chairs did such a fantastic job.

Thanks,
Bert 

> -----Original Message-----
> From: Loa Andersson [mailto:loa.andersson <at> utfors.se]
> Sent: zondag 3 november 2002 16:58
> To: MPLS wg
> Cc: Scott Bradner; George Swallow; Bert Wijnen
> Subject: mpls wg document status - update
> 
> 
> All,
> 
> at the last IESG meeting "a pile of mpls docs were discussed". This
> is a short update on doc status.
> 
> We have five new documents approved for publishing as 
> proposed standard
> 
>    <draft-ietf-mpls-ldp-ft-06.txt>
>    <draft-ietf-mpls-ldp-restart-06.txt>
>    <draft-ietf-mpls-lsp-hierarchy-08.txt>
>    <draft-ietf-mpls-rsvp-unnum-08.txt>
> 
> And one as an informational RFC
> draft-ietf-mpls-recovery-frmwrk-08.txt
> 
> All the documents will shortly show up on the RFC-editors queue.
> 
> Please join us in congratulating all the authors who have done
> a great job!
> 
> One document were returned to the working group to be coordinated
> with a parallel work in the idr wg
> 
>    <draft-ietf-mpls-bgp-mpls-restart-02.txt>
> 
> Contact has been taken with idr wg chair to see if there is anything
> that needs/could to be done from the mpls to speed up the process.
> 
> One document were returned to the authors (i.e. the mpls wg 
> chairs :) )
> for "word tweaking".
> 
>    <draft-andersson-mpls-sig-decision-01.txt>
> 
> Plan to "tweak" tomorrow, and hopefully the doc is back on the IESG
> agenda shortly.
> 
> Further information at:
> 
> http://urax.utfors.net/~loa/MPLS_WG_Drafts.htm
> 
> Loa and George.
> 
> 
> -- 
>      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           loa.andersson <at> utfors.se
>      WWW             www.utfors.se
> 
> 

Last Call: draft-ietf-mpls-bgp-mpls-restart-02.txt

idr working group, (mpls wg copied for information)

this is to initiate a last call on

    <draft-ietf-mpls-bgp-mpls-restart-02.txt>

The last call has been requested by the ADs and OKed by idr wg chairs.
The draft is a product of the mpls working group.

    In some scenarios BGP is used a the Label Distribution Protocol.
    A mechanism for BGP that would help minimize  the negative effects
    on routing caused by BGP restart is described in "Graceful Restart
    Mechanism for BGP" <draft-ietf-idr-restart-05>.
    <draft-ietf-mpls-bgp-mpls-restart-02.txt> extends this mechanism to
    also minimize the negative effects on MPLS forwarding caused by a
    restart of BGP when BGP is used to carry MPLS labels and the LSR
    (Label Switching Router) is capable of preserving the MPLS forwarding
    state across the restart.

Since the IETF meeting is upcoming and this is normally busy weeks, this
last call ends November 29th 5 PM EST.

/Loa

--

-- 
     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           loa.andersson <at> utfors.se
     WWW             www.utfors.se

MPLS LSP

Can any one help me answer these questions:

Would LSRs process IP frames that don't have MPLS shim header? Imagine
there are two edge LSRs (LER -A and LER-B) using an LSP, is it possible
for another router (non-MPLS) to send frames (using the IP address used
in this LSP, say LER-A's)? If so, is possible to have denial of service
over this LSP?

Thank,
Mudhafar